home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
AMOS PD CD
/
amospdcd.iso
/
aminet
/
amoslist0993.lzh
/
AMOSLIST2
/
000062_amos-request@svcs1.digex.net_Thu Sep 2 06:41:21 1993.msg
< prev
next >
Wrap
Internet Message Format
|
1993-09-03
|
4KB
Received: from nextsun.INS.CWRU.Edu by access.digex.net with SMTP id AA03375
(5.65c/IDA-1.4.4 for <mcox@access.digex.com>); Thu, 2 Sep 1993 06:41:19 -0400
Received: from svcs1.digex.net by nextsun.INS.CWRU.Edu with SMTP (5.65b+ida+/CWRU-1.5.2-freenet-gw)
id AA01077; Thu, 2 Sep 93 06:39:53 -0400 (from amos-request@svcs1.digex.net for mcox@access.digex.com)
Received: by svcs1.digex.net id AA18526
(5.65c/IDA-1.4.4 for amos-list-out); Thu, 2 Sep 1993 06:21:55 -0400
Received: from access.digex.net by svcs1.digex.net with SMTP id AA18522
(5.65c/IDA-1.4.4 for <amos-list@svcs1.digex.net>); Thu, 2 Sep 1993 06:21:47 -0400
Received: from wraith.cs.uow.edu.au by access.digex.net with SMTP id AA02298
(5.65c/IDA-1.4.4 for <amos-list@access.digex.net>); Thu, 2 Sep 1993 06:21:40 -0400
Received: by wraith.cs.uow.edu.au
(5.65c/IDA-1.4.4); id AA06694; Thu, 2 Sep 1993 20:21:13 +1000
(from u9147063@cs.uow.edu.au for amos-list@access.digex.net)
From: Richard Barry Ling <u9147063@cs.uow.edu.au>
Message-Id: <199309021021.AA06694@wraith.cs.uow.edu.au>
Subject: RE: Jumping/flickering/stuttering/have fits etc.
To: amos-list@access.digex.net (AMOS User group)
Date: Thu, 2 Sep 1993 20:21:11 +1000 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 2348
Status: RO
> Some people have said that the provided demo on the extras etc. had this
> stuttering problem (Example 10.10). I myself have not noticed this
> problem in those proggies.
> The manual does say it should be Screen Swap then Wait Vbl. If
> the Screen Swap is meant to occur just after the next Vblank then why do
> you need a Wait Vbl at all?? If you leave out the Wait Vbl's then 9 times
> out of 10 the flickering is worse (As I found in the game I am now writing).
The reason is that the Screen Swap command doesn't actually wait until
vertical blanking. It just swaps the physical and logical screen pointers.
This doesn't affect which screen is being displayed at that time - only at
the start of the next frame will the new screen appear - but it *does*
affect which screen drawing operations are performed on.
If you call Screen Swap when the video beam is halfway down the screen, the
screen which you are currently displaying beomes your logical screen. If
you then call drawing operations, you get flicker, caused by writing the
display memory. You have to wait until the vertical blank, when the current
logical screen gets flipped out of view, before you draw in it. That's why
you call Wait Vbl straight after Screen Swap.
> I haven't actually examined the code lately but I may have used
> Screen Copy instead of Scroll. This could be the problem as Screen Copy
> is slower (I think thats right I can't remember correctly, but I do know
> that after my tests on this I do now use scroll).
Shouldn't be slower. Internally, the operation is the same - shifting
memory blocks.
> ||\ ***********************************************
> ./~ \ * Scott Southurst (maverick@deakin.edu.au) *
> ~~\ \ * Deakin University, Warrnambool, Australia *
> // \ * Aquatic Biology/Computer Programming *
> | \___/| * A500 - 1084s - 1meg - AMOS 1.34 - AMOS 3d *
> /~/~~ ___/ * Compiler - AND LOVING IT!! (Soon A1200??) *
> ~~~~~~~~ ***********************************************
RL.
This has been a dinosaur-free announcement.
========================== Generating: .signature
Richard Ling - colour analysis... complete
u9147063@cs.uow.edu.au - clipping... complete
========================== - rendering... 37.6%